Hi, We are using Pactflow to verify service-to-ser...
# general
j
Hi, We are using Pactflow to verify service-to-service interactions across various environments like dev, int, preprod and prod. I am facing below 2 scenarios which needs your inputs to handle it? 1. Scenario - Microservices written before implementing Pact contract tests: We do have some microservices without contract tests and now running different versions in int, preprod and prod. So when we started implementing the contract tests for these microservices in dev, the Can-I-deploy tasks starts failing in int, preprod and prod. Because, the Can-I-Deploy checks for the pacticipant starts failing with the error message ":- No pacts or verifications have been published for version 567bcba1f3be811dccdf746184fc3d7781daea62 of <_pacticipant service name_>". So do you know how to handle this scenario? Because it is not always mandatory that we should start implementing the contract tests from day 1 & the microservice may start interacting with a new service after sometime. 2. Scenario - Messaged based testing: The Pact tests are seems to be very strict that the provider will only be verified with the contracts published by the consumer. If I wanted to promote an event provider (i.e. a Microservice) before a consumer , the contract verification step is failing in the tests due to missing consumer contracts. Is there any way, can I make this work without the much dependency on the consumer?
m
1. The only suggestion I have is to gradually add
can-i-deploy
to match your process 2. See https://docs.pact.io/pact_nirvana/notes_1
s
> 1. The only suggestion I have is to gradually add
can-i-deploy
to match your process what we did was implement can-i-deploy everywhere but use
--dry-run
flag until all pacts and verification results are published. We've also added a custom script to skip
can-i-deploy
if we're checking a version that's not present in the pact broker.
Also you can have a provider running
can-i-deploy
normally up until the point where a consumer publishes their first pact, so it makes sense to onboard providers first.
there's also an
--ignore
flag in
can-i-deploy
which would allow ignoring pacts with individual services as needed
☝️ 1
m
what we did was implement can-i-deploy everywhere but use
--dry-run
flag until all pacts and verification results are published.
I should have mentioned this as an option, but ultimately it still relies on the knowledge to “trust” or “not trust” the command in order to use it.
We’ve also added a custom script to skip
can-i-deploy
if we’re checking a version that’s not present in the pact broker. (edited)
clever! Are you using the
describe-version
command or a custom API call?
s
yeah, we're using
pact-broker describe-version
, we wrote a simple shell script that checks if
describe-version
returns
Pacticipant version not found
or some other error
👍 1
probably an api call would've been cleaner, but I haven't thought of that tbh 😅
😆 1